Techniques for dynamic updating and loading of custom application detectors

ABSTRACT

In various embodiments, a data-driven model is provided for an application detection engine for the detection and identification of network-based applications. In one embodiment, information can be input into an application detection database. The information may include a hostname, ports, transport protocol (TCP/UDP), higher layer protocol (SOCKS, HTTP, SMTP, FTP, etc), or the like. The information may be associated with a given application. The information may be used to create rule sets or custom program logic used by one or more various application detection engines for determining whether network traffic has been initiated by a given application. The information may be dynamically loaded and updated at the application detection engine.

CROSS-REFERENCES TO RELATED APPLICATIONS

This Applications claims the benefit of and priority to U.S. ProvisionalPatent Application No. 61/102,343, filed Oct. 2, 2008, entitled“Application Detection Architecture and Techniques,” and U.S.Provisional Patent Application No. 61/103,164, filed Oct. 6, 2008,entitled “Techniques For Dynamic Updating And Loading Of CustomApplication Detectors,” which are incorporated by reference herein intheir entirety for all purposes.

This Application is related to commonly owned copending U.S. patentapplication Ser. No. 12/568,073, filed Sep. 28, 2009, entitled“Application Detection Architecture and Techniques,” which is hereinincorporated by reference in its entirety for all purposes.

BACKGROUND OF THE INVENTION

This Application relates generally to systems for managing andprocessing information, and specifically to an architecture andtechniques for managing network-based applications accessed by computersystems and other devices.

With the advent of modern computers and computer networks, users havebeen provided with a faster electronic means of communicating with eachother. Browser applications, such as Internet Explorer from MicrosoftCorporation and Firefox from the Mozilla Foundation, can allow users tobrowse the world-wide web, obtain news information, share photos ormusic, or the like, through computer networks, such as the Internet. Inanother example, e-mail and instant messaging can allow users tointeract, for example, in real-time communications.

Computer networks can often include hundreds or thousands of networkhosts. A network host can be a computer or other hardware device thatruns software applications and originates and/or receives networktraffic. Network administrators may often be responsible for maintainingthese network hosts in proper running order. The network administratorsmay incorporate a variety of methodologies and devices in an attempt toensure that any computer network under their supervision operatessecurely and reliably. To that end, network administrators may often setrules or establish network policies for users, groups, and devices aboutthe types of software applications and network traffic allowed on anetwork.

Network applications may include software applications on a network hostthat are responsible for originating and/or receiving network traffic,referred to as network flows. Some network applications may bewell-behaved and conform with a network's rules and policies. Othernetwork applications may be poorly-behaved, installing without a user'sor network administrator's permission, hiding themselves and theiroperation, and violating a network's rules and policies. Examples ofpoorly-behaved network applications may include computer viruses, worms,spyware, and malware applications. Additionally, some more legitimateapplications, such as instant messaging applications, file-sharing orother types of peer-to-peer network applications, voice-over IP (VOIP)communication applications, and multimedia applications may beresponsible for network flows that can circumvent network policies andjeopardize network security and reliability.

Often, poorly-behaved network applications can attempt to conceal theirnetwork flows to avoid detection and disregard network policies. Commonevasion techniques may include using non-standard network protocols,dynamic port and channel selection, which limits the effectiveness ofmonitoring and blocking network ports to control network traffic;HTTP/HTTPS tunneling, which hides network flows in normally-permittedweb traffic; Peer-to-Peer onion routing, which selects destinationaddresses for peer-to-peer routing at random to circumvent destinationaddress blocking; and encryption of network packet data, which preventsnetwork monitors from examining the contents of network packets toidentify the type of network flow.

For example, some common peer-to-peer VOIP applications can circumventnetwork policies in a number of ways. The peer-to-peer VOIP applicationmay dynamically selected different ports and channels for communication.If UDP is blocked, the application can fall back on TCP/IP.Additionally, the peer-to-peer VOIP application may tunnel its data overopen ports 80 or 443, which are normally intended for HTTP or SSLtraffic. A peer-to-peer VOIP application may dynamically selectsupernodes in its peer-to-peer network to circumvent destination addressdetection and blocking. Additionally, data may be encrypted to preventdetection using packet inspection.

Some attempts at controlling network applications generally includemonitoring the content, size, and source and destination addresses ofnetwork flows as they pass through a gateway or other point in thenetwork. However, due to the above described evasion techniques, theseattempts at controlling network applications may have too littleinformation to reliably detect poorly-behaved network applications.Additionally, these attempts at controlling network applications mayfurther have too little information about who initiate an unauthorizednetwork flow.

Accordingly, what is desired is to solve problems relating to managingnetwork-based applications accessed by computer systems and otherdevices, some of which may be discussed herein. Additionally, what isdesired is to reduce drawbacks related to detecting and identifyingnetwork-based application that initiate network flows, some of which maybe discussed herein.

BRIEF SUMMARY OF THE INVENTION

In various embodiments, a data-driven model is provided for anapplication detection engine for the detection and identification ofnetwork-based applications. In one embodiment, information collectedabout network-based applications can be input into an applicationdetection database. The information may include information about anetwork-based application and its behavior, such as a hostname, ports,transport protocol (TCP/UDP), higher layer protocol (SOCKS, HTTP, SMTP,FTP, etc), or the like. Such information may be associated with a givennetwork-based application, a type of network-based application, a classor category of network-based applications, or the like. In variousembodiments, information collected about network-based applications andstored in one or more databases may be used to generate data structures,processing logic, or rule sets used by one or more various applicationdetection engines for determining whether network traffic within acomputer network has been initiated by a network-based application.

In some embodiments, one or more computer systems can be configured togenerating information for detecting network-based applications. Networktraffic sent to or received from a network application can be analyzedeither manually or automatically to identify one or more data pointsassociated with the network traffic that are characteristic of thenetwork-based application. Information describing the identified one ormore data points can be received receiving at least a first computersystem in a set of computer systems. The information describing theidentified one or more data points can be associated with thenetwork-based application. Information about the network-basedapplication, the information describing the identified one or more datapoints, and information associating the information describing theidentified one or more data points and the network-based application canthen be stored in a database.

A set of rules can be generated at least a second computer system in theset of computer systems in response to accessing the database thatconfigure an application detection engine to identify the network-basedapplication from network traffic. Each rule in the set of rules caninclude information specifying at least one of the one or moreidentified data points and information specifying one or more conditionswhen data in the network traffic associated with the at least one of theone or more identified data points satisfies the rule. The set of rulescan then be communicated to an application detection device. Theapplication detection functionality of the application detection devicecan be dynamically updated to support detection of the network-basedapplication based on the communicated set of rules.

In further embodiments, the set of rules may be packaged into a formatappropriate for the application detection device. The packaged set ofrules may be distributed electronically, such as via download, orphysically distributed using information storage media. Analyzing thenetwork traffic sent to or received from the network application mayinclude identifying one or more of a source address, a destinationaddress, a source port, a destination port, one or more header fields,payload data, or combinations thereof. Information about thenetwork-based application may include one or more of a filename, adownload location, a URL, a hostname, or a domain name associated withthe network-based application.

In still further embodiments, information may be received describinglogic for determining information using one or more of the identifiedone or more data points. The logic then may be associated with thenetwork-based application. The logic and information associating thelogic and the network-based application may be stored in the database.In one embodiment, program code may be generated based on the logic. Theprogram code then can be compiled for execution at the applicationdetection device. The program code may be compiled for dynamic loadingat the application detection device. The compiled program code may alsobe communicated to the application detection device. In one embodiment,the application detection functionality of the application detectiondevice may be dynamically updated to support detection of thenetwork-based application based on the communicated set of rules and thecompiled program code.

In various embodiments, the information describing the logic may includelogic for maintaining stating information across the network traffic.The information describing the logic may include logic for determiningone or more hash values or checksum from the network traffic. Dynamicupdated of at least the application detection functionality of theapplication detection device to support detection of the network-basedapplication based on the communicated set of rules may include updatedat start-time or during run-time.

In some embodiments, at least one or more user interfaces of theapplication detection device may be dynamically updated to supportdisplaying of information associated with the network-based applicationbased on the communicated set of rules. At least reporting functionalityof the application detection device may be dynamically updated tosupport reporting of information associated with the network-basedapplication based on the communicated set of rules.

In one embodiment, one or more information storage media or acomputer-readable storage medium stores code executable by a processorof a computer system for detecting network-based applications, Thecomputer-readable storage medium can include code for receivinginformation describing one or more data points, the one or more datapoints identified in response to an analysis of network traffic sent toor received from a network application to identify a set of data pointsassociated with the network traffic that are characteristic of thenetwork-based application, code for associating the informationdescribing the identified one or more data points with the network-basedapplication, code for storing information about the network-basedapplication, the information describing the identified one or more datapoints, and information associating the information describing theidentified one or more data points and the network-based application ina database, code for generating a set of rules in response to accessingthe database that configure an application detection engine to identifythe network-based application from network traffic, each rule in the setof rules specifying at least one of the one or more identified datapoints and one or more conditions when data in the network trafficassociated with the at least one of the one or more identified datapoints satisfies the rule, and code for communicating the set of rulesto an application detection device, wherein at least applicationdetection functionality of the application detection device isdynamically updated to support detection of the network-basedapplication based on the communicated set of rules.

In one embodiment, a system for detecting network-based applications caninclude a database configured to store information about a network-basedapplication. The system may also include a first set of one or morecomputer systems configured to receive information describing the one ormore data points, the one or more data points determined in response toan analysis of network traffic sent to or received from the networkapplication to identify a set of data points associated with the networktraffic that are characteristic of the network-based application,associate the information describing the identified one or more datapoints with the network-based application, and store the informationabout the network-based application, the information describing theidentified one or more data points, and information associating theinformation describing the identified one or more data points and thenetwork-based application in the database. The system may furtherinclude a second set of one or more computer systems configured togenerate a set of rules in response to accessing the database thatconfigure an application detection engine to identify the network-basedapplication from network traffic, each rule in the set of rulesspecifying at least one of the one or more identified data points andone or more conditions when data in the network traffic associated withthe at least one of the one or more identified data points satisfies therule, and communicate the set of rules to an application detectiondevice, wherein at least application detection functionality of theapplication detection device is dynamically updated to support detectionof the network-based application based on the communicated set of rules.

A further understanding of the nature of and equivalents to the subjectmatter of this disclosure (as wells as any inherent or expressadvantages and improvements provided) should be realized by reference tothe remaining portions of this disclosure, any accompanying drawings,and the claims in addition to the above section.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to reasonably describe and illustrate those innovations,embodiments, and/or examples found within this disclosure, reference maybe made to one or more accompanying drawings. The additional details orexamples used to describe the one or more accompanying drawings shouldnot be considered as limitations to the scope of any of the claimedinventions, any of the presently described embodiments and/or examples,or the presently understood best mode of any innovations presentedwithin this disclosure.

FIG. 1 is a block diagram of a system for detecting and identifyingapplications that initiate network traffic in one embodiment accordingto the present invention;

FIG. 2 is a simplified flowchart of a method for detecting and managingnetwork-based applications using a data-driven model in one embodimentaccording to the present invention;

FIG. 3 is a flowchart of a method for identifying a given applicationfrom network traffic in one embodiment according to the presentinvention;

FIG. 4 is a flowchart of a method for generating rules for singleinspection point dissection (SIP), multiple inspection point dissection(MIP), and custom dissector code in one embodiment according to thepresent invention;

FIG. 5 is a flowchart of a method for packaging application signaturesin one embodiment according to the present invention;

FIG. 6 is a block diagram of an embodiment of a network traffic managerin one embodiment according to the present invention;

FIG. 7 is a flowchart of a method for updating detectable applicationsin one embodiment according to the present invention;

FIG. 8 is a flowchart of a method for detecting applications fromnetwork traffic in one embodiment according to the present invention;and

FIG. 9 is a simplified block diagram of a computer system that mayincorporate embodiments of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

In various embodiments, a data-driven model is provided for anapplication detection engine for the detection and identification ofnetwork-based applications. In one embodiment, information collectedabout network-based applications can be input into an applicationdetection database. The information may include information about anetwork-based application and its behavior, such as a hostname, ports,transport protocol (TCP/UDP), higher layer protocol (SOCKS, HTTP, SMTP,FTP, etc), or the like. Such information may be associated with a givennetwork-based application, a type of network-based application, a classor category of network-based applications, or the like. In variousembodiments, information collected about network-based applications maybe used to generate data structures, processing logic, or rule sets usedby one or more various application detection engines for determiningwhether network traffic within a computer network has been initiated bya network-based application.

In some embodiments, periodically, or upon demand, an applicationdetection database storing information collected about network-basedapplications can be accessed to generate data structures, processinglogic, or rule sets that configure single and multiple inspection pointapplication detection engines. The structures, processing logic, or rulesets can be packaged into one or more filter updates which can bedistributed using a communications network to network traffic managersconfigured as application detection devices. The one or more filterupdates can include structures, processing logic, or rule sets, as wellas dynamic libraries and application meta-information.

In further embodiments, information collected about network-basedapplications may be used to generate application-specific segments ofcode usable by an application detection engine. A customized segment ofcode, referred to as a custom dissector, can be compiled as adynamically loadable library (e.g., a ‘C’ library) that can be installedand loaded by an application detection engine. A custom dissector alsomay be uninstalled, altered, and reinstalled without relinking orrecompiling a main program of an application detection engine.

In some embodiments, a network traffic manager configured as anapplication detection device may not have prior a priori awareness of aset of given detectable applications that:

-   -   may be displayed or otherwise made accessible to a user, used in        a “dashboard,” or appear in the output of reports;    -   for which the application detection device can gather “use”        statistics;    -   can in fact be detected, blocked or in some other manner,        managed by the application detection device;    -   are associated with any of one or more categories to which a        given detectable application belongs; or    -   are association with any of one or more descriptions of a given        detectable application that may be shown to the user or provided        for reporting purposes.

Therefore, in some embodiments, a network traffic manager configured asan application detection device may be periodically updated with customdissector dynamic libraries. An application detection device may containa routine, when called by a bootstrapping process of a main program ofthe application detection device, that contains information making themain program “aware” of various dynamically loadable libraries forcustom dissectors and when to call upon a given custom dissector toperform the application or protocol detection attributed to the customdissector. In a further embodiment, the dynamic aspect of theapplication management can also extend to graphical user interface (GUI)components, reporting components, or the like, of an applicationdetection device.

One or more examples of aspects and environments in which the variousdisclosed techniques for dynamic updating and loading of customapplication dissectors will now be provided.

In various embodiments, techniques are provided for detecting andidentifying applications that initiate network flows. In one embodiment,a layered approach to application detection provides scalability andspeed, while further providing quick assessments that move from simplestto complex for rapid detection. For example, in a 1st Tier of singleinspection point (SIP) engines, a series or sequence of one or moreinspection engines are utilized that provide a single look analysis at anetwork flow, such as for information from a single packet, a URL,hostname, IP, or the like. In a 2nd Tier of multiple inspection point(MIP) engines, a series or sequence of one or more inspection enginesare utilized to generate a correlation between a set of multiple datapoints in the network flow, such as using string matching, USER_AGENT,packet number, flow direction, stream offset, connection type, or thelike. In a 3rd Tier, custom dissectors can be called from the MIP tieror SIP tier for use as a final stage fall through for deep analysis ofthe network flow. In one embodiment, the 3rd Tier may be used whenpacket spanning is required to determine the identity of an applicationthat originated the network flow.

In various embodiments, an application detection architecture mayincorporate these techniques and well as others that include,two-dimensional hashing, sparsely populated arrays, an integer-orientedapproach to string matching, protocol state information maintained in“probes,” wide use of shared memory, and dynamic loaded libraries and“filter updates” for scalability, speed, and to offer quick assessmentsfor rapid detection. In some embodiments, as a result, network packetsmay be thus examined in real-time or substantially in real-time, forexample, at 1 Gbit line rates. Accordingly, an application detectionarchitecture may be employed that utilizes techniques that arecomputationally fast, yet accurate for their purposes.

In further embodiments, an application detection architecture mayincorporate the multiple (e.g., three) tiers or processing layers tobalance detection accuracy and computational requirements, such as:

-   -   A 1st Tier: Rapid quick-hit packet engine that addresses, for        example, up to ˜60% or more of the application space.    -   A 2nd Tier: More complex engine that effectively conducts        multiple tests that addresses, for example, up to ˜35% or more        of the application space.    -   A 3rd Tier: Customized engine for in-depth analysis also capable        of packet spanning needed for, for example, up to ˜5% or more of        the application space.

FIG. 1 is a block diagram of system 100 that may incorporate techniquesfor detecting and identifying applications that initiate network flowsin various embodiments according to the present invention. In thisexample, system 100 can include a plurality of clients 110 (e.g., client110A, client 110B, and client 110C), network traffic manager 120,communications network 130, firewall 140, communications network 150,server 160, and host 170.

Clients 110 can include hardware and/or software elements configured forsending and/or receiving network traffic (e.g., network flows). Someexamples of clients 100 are any computing devices, such as any computersystems, personal computers (PC), laptops, workstations, networkappliances, mainframes, pocket PCs, personal digital assistants (PDAs),smartphones (BLACKBERRY OR IPHONE devices), telephones, cellular phones,pagers, etc, or other systems or devices having programmable processorsor logic circuitry. Clients 110 may be embodied as network hosts thatinclude operating systems and software applications that are responsiblefor originating and/or receiving network flows. In one example, client110A may host software applications that send instant message (IM)communications that include textual messages. In another example, client110B may host web-based applications that send application-specificcommunications that include encrypted or compressed data. In yet anotherexample, client 110C may host software applications that proxy or relayVOIP communications between two or more network hosts.

Network traffic manager 120 can include hardware and/or softwareelements configured for managing network flows associated withcommunications network 130. One example of components of network trafficmanager 120 is discussed further with respect to FIG. 2. Network trafficmanager 120 may be embodied as any computing device, such as clients110, and may be implemented as a standalone device, a network appliance,a virtual machine, or the like. In some embodiments, network trafficmanager 120 may be embodied as a hardware and/or software component of asystem offering network services, such as firewall protection, intrusiondetection, antivirus/malware detection, host configuration services,domain name services, directory services, file/printer sharing services,or the like.

In some embodiments, network traffic manager 120 may be implemented in aproxy server model, a server model, an event model, or any combinationthereof. In a proxy server model, network traffic manager 120 may besituated to be in communication with communications network 130 andconfigured to act as a proxy or intermediary for communications betweenclients 110 and hosts coupled to communications networks 130 and 150.Network traffic manager 120 may support one or more communicationsprotocols, such as any kind of open source, commercially available, orreverse engineered proprietary protocols, and proxy mechanisms thereof(e.g., SOCKS, HTTP, HTTPS). In a proxy server model, network trafficmanager 120 may intercept network traffic or network flows originatingfrom or destined to clients 110. In one example, client 110A may connectto hosts coupled to communications networks 130 and 150 forcommunication using network traffic manager 120 by specifying host andport settings of network traffic manager 120 in proxysettings/preferences of client 110A. Network traffic manager 120 maythen negotiate connections and communications on behalf of and to client110A.

In a server model, network traffic manager 120 network traffic manager120 may be situated to be in communication with communications network130 and configured to communicate with hosts coupled to communicationsnetworks 130 and 150 in a client-server fashion. Network traffic manager120 may support one or more communications protocols, such as any kindof any kind of open source, commercially available, or reverseengineered proprietary protocols, (e.g., HTTP, HTTPS, FTP, SMTP, POP3,IMAP, IM protocols, SIP, etc.). For example, network traffic manager 120may communicated with client 110B using a proprietary messaging protocolthat is specially defined for use between client 110B and networktraffic manager 120.

In an event model, network traffic manager 120 may be situated to be incommunication with another system or device (e.g., directly or throughcommunications network 130) and configured to interact with the anothersystem or device based on one or more events generated by the anothersystem or device. In various embodiments, network traffic manager 120may be coupled directly or indirectly to a router or network appliancedeployed in communications network 130. In one example, a router ornetwork appliance may be responsible for sending events to networktraffic manager 120 based on an analysis of a network flow. An event mayinclude information indicating an occurrence in network traffic observedby a router or network appliance (e.g., an HTTP GET request, an IMclient signed on/off; an IM client sent a text message to another IMclient; the presence status of an IM client has changed; or the like).Once receiving an event, network traffic manager 120 may processinformation sent with the event or access event information from therouter or appliance through an interface (typically an applicationprogrammer's interface, or API for short). Network traffic manager 120thus receives events encapsulating various details concerning networktraffic flows.

Communications network 130 can include hardware and/or software elementsconfigured for communicating data. Some examples of communicationsnetwork 130 can include a public network, a private network, anenterprise local area network, an extranet, a wide area network, ametropolitan area network, or the like. In some embodiments,communications network 130 may form an enterprise network that definedby firewall 140. Firewall 140 can include hardware and/or softwareelements configured for managing communications between communicationsnetworks 130 and 150, often to prevent information from leavingcommunications network 130 or limit exposure to attacks fromcommunications network 150. In these embodiments, any devices behindfirewall 140 may be considered part of the enterprise network. Otherdevices outside of firewall 140 may be considered to be outside of theenterprise network. Accordingly, clients 110 and network traffic managercan be considered part of the enterprise network. Although firewall 140is shown, it can be understood that firewall 140 may not be included insystem 100.

Communications network 150 can include hardware and/or software elementsconfigured for communicating data. Some examples of communicationsnetwork 150 can include a public network, a private network, anenterprise local area network, an extranet, a wide area network, ametropolitan area network, the Internet, or the like. In someembodiments, communications network 150 may provide network access toone or more servers, hosts, or information sources, such as server 160or host 170. Server 160 can include hardware and/or software elementsconfigured for providing services to one or more of clients 110. Forexample, server 160 may include a server computer providing a webserver, an application server, an FTP server, a VoIP server, or thelike. Host 170 can include hardware and/or software elements configuredfor communicating with one or more of clients 110. For example, host 170may include a server computer, network host, or other device providing apeer-to-peer (P2P) program, an instant messaging client or other chatprogram, a Skype or VOIP endpoint, or the like.

In one example of operation, network traffic monitor 120 may include orform part of an application detection architecture that attempts todetect and identify network-based applications from network traffic orflows. Network traffic monitor 120 may receive network traffic that mayhave been initiated by or originated from one or more network-basedapplications. A network-based application can include any softwareapplication, application component, plug-in, module, or set of codeconfigured for sending data to a network host through a communicationsnetwork or any software application, application component, plug-in,module, or set of code configured for receiving data send from a networkhost through a communications network. Network traffic monitor 120 mayemploy one or more dissection engines or application detection tests todetect and identify network-based applications from the network traffic.Once an application is identified, network traffic monitor 120 maydetermine and/or enforce rules, policies, procedures, audits, or thelike, based on the detected applications or devices/users/groupsassociated with the detected application.

FIG. 2 is a block diagram of an embodiment of network traffic manager120 that may be included in system 100 of FIG. 1 in one embodimentaccording to the present invention. Network manager 120 may be embodiedas a single computing device or as multiple computing devicesimplementing different aspects of the disclosed functionality. In thisexample, network traffic manager 120 includes transceiver module 205,network traffic module 210, policy module 215, and action module 220.

Transceiver module 205 can include hardware and/or software elementsconfigured for receiving data, such as from communications networks 130and 150 or directly from another device, and for transmitting data, suchas to a host coupled to one of communications networks 130 and 150 ordirectly to another device. In one embodiment, transceiver module 205may include inbound transceiver module 225 and outbound transceivermodule 230. Inbound transceiver module 225 can include hardware and/orsoftware elements configured for receiving data. Inbound transceivermodule 225 may handle network traffic received at one or morecommunications interfaces (not shown) associated with network trafficmanager 120, such as from clients 110 or server 160 of FIG. 1. Outboundtransceiver module 230 can includes hardware and/or software elementsconfigured for transmitting data. Outbound transceiver module 230 mayhandle network traffic generated by or originating from network trafficmanager 120 for transmission via one or more communications interfaces(not shown) associated with network traffic manager 120, which mayinclude network traffic generated on behalf of clients 110 or to server160.

In various embodiments, transceiver module 205 can be communicativelycoupled to network traffic module 210. Network traffic module 210 caninclude hardware and/or software elements configured for analyzingnetwork traffic. In one example, network traffic module 210 may beresponsible for identifying an application that produced the networktraffic or network flow. In another example, network traffic module 210may be responsible for identifying users, groups, and/or machinesresponsible for the network traffic. In other embodiments, networktraffic manager may directly or indirectly determine or enforce rules,policies, privileges, or the like, for detected applications.

In some embodiments, network traffic module 210 can receive networkflows to be analyzed or data about the network flows to be analyzed fromdifferent sources. For example, network traffic monitor 120 may receivenetwork traffic or network flows monitored directly in system 100. Inanother example, network traffic monitor 120 may receive data aboutnetwork flows from another device in system 100, such as one or more ofclients 110. Network traffic module 210 can collect the information onnetwork flows being sent from or received by network-based applicationswithin system 100. Some examples of the information collected, eitherdirectly from network traffic or from other sources can include thesource and destination addresses of network packets, the size of networkdata in network packets, the contents of network packets, the rate ofrelated network packets in a network flow, other attributes of one ormore network packets in a network flow, host information, userinformation, operating system information, or the like.

In various embodiments, network traffic module 210 can use theinformation on network flows being sent from or received bynetwork-based applications to reliably identify the network flows andany associated network-based applications. Network traffic module 210may employ a variety of techniques for detecting and identifying a givennetwork-based application. In some embodiments, a layered approach toapplication detection provides scalability and speed, while furtherproviding quick assessments that move from simplest to complex for rapiddetection. For example, in a 1st Tier of single inspection point (SIP)engines, a series or sequence of one or more inspection engines areutilized that provide a single look analysis at a network flow, such asfor information from a single packet, a URL, hostname, IP, or the like.In a 2nd Tier of multiple inspection point (MIP) engines, a series orsequence of one or more inspection engines are utilized to generate acorrelation between a set of multiple data points in the network flow,such as using string matching, USER_AGENT, packet number, flowdirection, stream offset, connection type, or the like. In a 3rd Tier,custom dissectors can be called from the MIP tier or SIP tier for use asa final stage fall through for deep analysis of the network flow. In oneembodiment, the 3rd Tier may be used when packet spanning is required todetermine the identity of an application that originated the networkflow.

For example, network traffic module 210 may include single inspectionpoint (SIP) engine 240, multi-inspection point (MIP) engine 250, andcustom dissector engine 260. SIP engine 240, MIP engine 250, and/orcustom dissector 260 may include one or more inspection engines. Theseinspection engines may be loaded at startup or runtime for networktraffic processing and application detection. An inspection engine maybe configured by configuration data, such as detection rules that may bedynamically loaded and updated. Some examples of inspection engines thatmay be employed by SIP engine 240, MIP engine 250, and/or customdissector 260 can include:

Protocol Parsing Engine—a component that can parse IP and TCP headers togarner information useful later in later detection stages. The enginemay attempt to identify session layer protocols as well, such as HTTP,SMTP, HTTPS, FTP, or the like.

IP Address Inspection Engine—a component that can check for IP addressesthat have been associated with managed applications. The engine may makeidentifications based solely on both host IP addresses, but in someembodiments, may also work on a range of IP addresses, such as whensupplied with a netmask. The engine may further provide identificationsthat involve IP addresses combined with port numbers.

Hostname to IP Address conversion—a component that can convert hostnamesto IP addresses. Since the association between hostnames and IPaddresses can be fluid and may change, the engine may periodically checkwith the DNS system to retrieve DNS information, such as a hostnames'current IP addresses.

HTTP Hostname Inspection Engine—a component that can examine hostnamesin an HTTP header to identify managed HTTP-based protocols.

HTTP URL Inspection Engine—a component that can inspect HTTP URLs toidentify managed HTTP-based protocols.

Octet Inspection Engine—a component that can inspect payloads (e.g., TCPor UDP payloads) for recognizable sequences of octets (e.g., strings).

Dynamically Loaded Custom Dissectors—a component that can control ormanage a collection of protocol specific detectors. These protocolspecific detectors may be loaded dynamically at run-time.

Probe System for tracking historical information. In some embodiments,custom dissectors may include a system for tracking state informationthat transcends multiple packets. This information can be protocol andcustom dissector specific.

SIP engine 240 can include hardware and/or software elements configuredfor identifying a network-based application from network traffic or anetwork flow using at least one inspection point. In one example, aninspection point may include at least one data point in network trafficor a network flow, such as an IP address, a URL, a hostname, a domain ordomain name, a filename, or the like. SIP engine 240 may be embodied asa single engine configured to perform a series or sequence of SIP testsor as a logical series or sequence of SIP test-specific engines. SIPengine 240 may generate information used to identify a network-basedapplication from the network traffic or network flow and indicatorsquantifying confidence that the network-based application has beenidentified. SIP engine 240 may further generate information used toinvoke MIP engine 250 or Custom dissector engine 260 for furtheranalysis.

MIP engine 250 can include hardware and/or software elements configuredfor identifying a network-based application from network traffic or anetwork flow using one or more inspections points. The one or moreinspection points may include multiple data points or combinations ofinformation that represent a data structure, such as a SIP signature,Src/Dest IP:Port, or a combination of information such as packet number,packet length, stream offset, connection type (HTTPS, SOCKS, UNKNOWN,HTTP, HTTP_DIRECT, etc.), packet flow direction, variable stringpatterns, or the like. MIP engine 250 may be embodied as a single engineconfigured to perform a series or sequence of MIP tests or as a logicalseries or sequence of MIP test-specific engines. MIP engine 250 maygenerate information used to identify a network-based application fromthe network traffic or network flow and indicators quantifyingconfidence that the network-based application has been identified. MIPengine 250 may further generate information used to invoke Customdissector engine 260 for further analysis.

Custom dissector engine 260 can include hardware and/or softwareelements configure for identifying a network-based application fromnetwork traffic or a network flow using application-specific code. Theapplication-specific code can include data structures and/or processinglogic that configure Custom dissector engine 260 to more thoroughlyanalyze the network traffic or network flow. For example, anetwork-based application may not be readily identified by inspectingindividual or multiple data points in packet headers or packet contents.Processing logic associated with application-specific code may be usedto compute checksums or maintain state across multiple data points ormultiple packets to identify a network-based application.

In various embodiments, network traffic module 210 can becommunicatively coupled to and interface with policy module 215. Policymodule 215 can include hardware and/or software elements configured forproviding and enforcing policies for network traffic or network flows. Apolicy can include a set of rules, conditions, and actions. A policy mayfurther be associated with one or more users, groups of users,applications, devices, machines, or the like. Policies can be used toblock, throttle, accelerate, enhance, or transform network traffic thatis part of an identified network flow. In an embodiment, policies fornetwork flows may be enforced by network traffic controlling devicessuch as switches, routers, firewalls, proxies, IPS, and EPS systems.Network traffic module 210 and policy module 215 can communicate withnetwork traffic controlling devices via any interface or protocol, suchas SNMP.

Policy module 215 may be configure to access a number of policies. Inone embodiment, policy module 215 may include policy database 255 thatstores a set of policies. As shown, policy database 255 is located inpolicy module 215; however, it will be understood that policy database255 may be located anywhere in network traffic manager 120 or beseparate from network traffic manager 120.

The policies in policy database 255 may include information aboutactions that can be taken by network traffic monitor 120. The policiesmay be applied to a packet, group of packets, a network flow, a user, adevice, or the like. Policy module 215 may determine from userinformation, group information, machine information, characteristicsrelated to network flows, or the like whether any policies in policydatabase 255 applies. Policy module 215 may communicate with networktraffic module 210 to enforce policies for detected applications. Once apolicy is determined by policy module 215, action module 220 may beconfigured to perform the action corresponding to the determined policy.

In various embodiments, database 260 may be used to store informationusable for network traffic monitor 120. Database 260 may be included innetwork traffic monitor 120 or be separate from network traffic monitor120. In one embodiment, database 260 can includes one or moreinformation items including but not limited to: credential information,user information, user to IP address mappings, client identificationsfor clients 110, policies that may be implemented by policy module 215,or the like. This information is used by modules in network trafficmanager 120 for any purpose.

Accordingly, in various embodiments, network traffic manager 120 candetect and identify network-based applications that initiate networkflows. A layered approach employed by network traffic manager 120 insome embodiments to application detection can provide scalability andspeed, while further providing quick assessments that move from simplestto complex for rapid detection and policy enforcement.

FIG. 3 is a simplified flowchart of method 300 for detecting andmanaging network-based applications using a data-driven model in oneembodiment according to the present invention. The processing of method300 depicted in FIG. 3 may be performed by software (e.g., instructionsor code modules) when executed by a central processing unit (CPU orprocessor) of a logic machine, such as a computer system or informationprocessing device, by hardware components of an electronic device orapplication-specific integrated circuits, or by combinations of softwareand hardware elements. Method 300 depicted in FIG. 3 begins in step 310.

In step 320, signature discovery is performed. Signature discovery caninclude one or more manual or automated processes in which informationis collection about a network based application or its behavior. Invarious embodiments, a team of engineers and/or other network-basedapplication investigators can collect information about network-basedapplications or their behavior and store the information in a database.The information collection about a network based application or itsbehavior may represent a signature. A signature can include one or moreportions of information that identify an application from networktraffic initiated or otherwise generated by the application, from itsbehavior, from where it was downloaded or developed, resources used oraccessed, or the like. In some embodiments, an application signature mayinclude a single data element or data point, such as a predeterminedvalue found within a portion packet. In other embodiments, anapplication signature may include a plurality of data elements. In yetfurther embodiments, an application signature may include one or moredata elements, or data structures having one or more values, that may bedetermined, interpreted, or calculated using logic or coding fromnetwork traffic. An application signature may be generated by a manualprocess or by a completely automated process from information retrievedfrom a database using a data model.

In step 330, signature update packaging is performed. For example, a setof one or more application signatures may be “packaged” into adownloadable file or distributable format. The packaging process mayincorporate one or more application signatures, including any datastructures or program logic, as well as other metadata, code, rule sets,registry information, access control lists, policies, securityinformation, or other information updates. The packaging process may becumulative (e.g., including all application signatures resulting from apredetermined discovery process) or may be incremental (e.g., includingonly those application signatures resulting after a predetermined timeor event).

In step 340, a signature update is downloaded. For example, networktraffic manager 120 may connect to server 160 or host 170 to downloadone or more filter updates. A filter update can include information madeavailable according to the above packaging process. In otherembodiments, a signature update may be distributed on physical media andinstalled or added to network traffic manager 120 using a manualprocess.

In step 350, application detection via dynamic signature loading isperformed. In various embodiments, a main program of network trafficmanager 120, when configured as an application detection device, maydynamically and/or automatically install, initialize, update, reinstall,uninstall, or the like, configurations for one or more inspectionengines used in application detection. These configurations may includeconfigurations for single inspection point engines, multiple inspectionpoint, and custom inspection point engines.

Accordingly, with dynamic signature loading, network traffic manager 120may be configured at any time with a list of unauthorized network-basedapplications for the purposes of detection, reporting, and interfacingwith users of network traffic manager 120. In step 360, reporting onapplication detection via signature update is performed. As discussedabove, network traffic manager 120 does not need a priori knowledge ofall detectable applications. Applications that may be monitored bynetwork traffic manager 120 can be enabled for detection via signatureupdates. The signature updates may further configure network trafficmanager 120 for the purposes of reporting, logging, user interfaceupdating, or the like. Method 300 depicted in FIG. 3 ends in step 370.

As discussed above, signature discovery can include one or more manualor automated processes in which information is collection about anetwork based application or its behavior. In various embodiments, ateam of engineers and/or other network-based application investigatorscan collect information about network-based applications or theirbehavior and store the information in a database. The informationcollection about a network based application or its behavior mayrepresent a signature.

FIG. 4 is a flowchart of method 400 for identifying a given applicationfrom network traffic in one embodiment according to the presentinvention. Method 400 depicted in FIG. 4 begins in step 410.

In step 420, one or more network traffic elements or data points areidentified. For example, a given network-based application may beassociated with an application-specific protocol. Therefore, networktraffic generated by or otherwise originating from the network-basedapplication may conform to a recognizable format (i.e., theapplication-specific protocol). One or more inspection or data points innetwork traffic may be established from particular bytes of a packet,predetermined fields within a header, source network addresses/ports,destination network addresses/ports, payload structure, payloadcontents, transmission control parameters, flow control information,state obtained from a sequence of packets, string matching, checksums,presences/absence of encryption, statistical models, behavioral models,or the like.

In step 430, one or more inspected or identified data points areassociated with an application. The one or more inspected or identifieddata points network traffic may be associated with a singlenetwork-based application or with types/categories of network-basedapplications. In one example, network traffic destined for IP port 21may usually be associated with file transfer protocol (FTP)applications. In another example, network traffic destined for aspecific IP address that maps to a predetermined domain and/or hostnameand that includes a specific URL may be associated with an HTTP-basedapplication hosted by the predetermined domain. Accordingly, informationcollected directly from network traffic generated by a network-basedapplication, indirectly about the applications operation, and the like,may be associated with an application.

In step 440, information associating the one or more identified datapoints with the application is stored. For example, the information maybe stored in an application detection database 350. Applicationdetection database 450 may include the data points, metadata associatedwith each data point, an application description, logic correlating oneor more data points, or the like. Method 400 depicted in FIG. 4 ends instep 460.

In various embodiments, a service provide can use information stored inapplication detection database 450 to generate application signatures,rules, or program code used by network traffic manager 120 fordetecting, identifying, and managing network-based applications.Confirmation information may be manually or automatically generated todynamically and/or automatically install, initialize, update, reinstall,uninstall, or the like, configurations for one or more inspectionengines used in application detection. These configurations may includeconfigurations generated from application detection database 450 forsingle inspection point engines, multiple inspection point, and custominspection point engines.

FIG. 5 is a flowchart of method 500 for generating rules for singleinspection point dissection (SIP), multiple inspection point dissection(MIP), and custom dissector code in one embodiment according to thepresent invention. Method 500 depicted in FIG. 5 begins in step 510.

In step 520, information associating one or more data points with anapplication is received. For example, information obtained fromapplication detection database 450 of FIG. 4 may include an applicationname, information describing how or where to determine the one or moredata points in network traffic, logic for determining or calculatingvalues from the one or more data points, or the like.

In step 530, one or more rules or rule sets for a single inspectionpoint (SIP) engine or a multiple inspection point (MIP) engine aregenerated or custom dissector code is generated based on theinformation. A rule may indicated a set of inputs or conditions and aset of outputs for when the inputs or conditions are met, matched, orotherwise satisfied. In one example, a rule is executed or otherwiseapplied by a given inspection engine or inspector which includesinformation specifying which data point the given inspection engine orinspector needs to inspect (e.g., what byte or set of bytes of a packetare to be looked at) and information indicative of a predetermined valueor expected result that when matched with the data point causes the ruleto be satisfied or otherwise generated an match condition or indication.

In various embodiments, custom dissector code may include data structureand/or logic represented by software code that can be compiled into acustom dissector. The custom dissector may be dynamically loaded orinvoked from a rule executed by a SIP or MIP engine for a variety orreasons. For example, a given rule may produce a certain number of falsepositives or false negatives under certain conditions. Those certainconditions may be covered by a custom dissector that reevaluates theapplication detection indication provided by the SIP/MIP engine. Inother embodiments, a custom dissector may be directed to anapplication-specific protocol whose complexity may not readily beestablished by data point specific inspection engines.

In step 540, code representing any custom dissectors may be compiled forexecution. In some embodiments, the code may be complied into nativecode. In other embodiments, the code may be complied into byte code foran interpreted language. Method 500 depicted in FIG. 5 ends in step 550.

FIG. 6 is a flowchart of method 600 for packaging application signaturesin one embodiment according to the present invention. Method 600depicted in FIG. 6 begins in step 610, where, one or more rules for asingle inspection point (SIP) engine or a multiple inspection point(MIP) engine are received and/or custom dissector code is received.

In step 630, application/signature ID assignment is performed. IDassignment may be performed using an application/signature archive whereIDs for previously packaged signatures for applications may be retrievedand new IDs may be assigned. In step 640, signature updated formattingis performed. In step 650, signature header file generation isperformed. In step 660, the packaged signature update is uploaded to adownload site, such as a website, FTP site, bittorrent site, or thelike. The signature update is then available for download to one or moreapplication detection devices, such as network traffic manager 120 ofFIG. 1. Method 600 depicted in FIG. 6 ends in step 670.

FIG. 7 is a flowchart of method 700 for updating detectable applicationsin one embodiment according to the present invention. Method 700depicted in FIG. 7 begins in step 710. For example, a download URL maybe provided to network traffic manager 120.

In step 720, a signature update is downloaded. As discussed above, thesignature update may include rules, custom dissectors, or otherinformation for configuring and operating application detection usingSIP engine 240, MIP engine 245, and Custom Dissector 250. In step 730,signature update parsing is performed.

In step 740, the signature update is imported in an applicationdetection database 750. In step 770, any necessary applicationsignatures (e.g., rules and/or dynamically loadable custom dissectors)are loaded at or during run time. Method 700 depicted in FIG. 7 ends instep 780.

FIG. 8 is a flowchart of method 800 for detecting applications fromnetwork traffic in one embodiment according to the present invention.Method 800 depicted in FIG. 8 begins in step 805.

In step 810, network traffic (e.g., one or more packets) is parsed. Forexample, identification can be made of various individual data points,such as source IP address, source port, destination IP address,destination port, protocol type, URL, hostname, domain name, or thelike. In step 815, SIP signature testing is performed. If SIP signaturetesting provides a pass result in step 815, then in step 820, the SIPsignature is released providing an indication of a detected application.

If SIP signature testing provides a fail result in step 815, in step825, the network traffic may be further parsed. For example,identification may be made of a combination of data points, such asstrings, unique byte offsets, HTTP header information, or the like. Instep 830, MIP signature testing is performed. If MIP signature testingprovides a pass result in step 830, in step 835, the MIP signature isreleased providing an indication of a detected application.

If MIP signature testing provides a fail result in step 830, in step840, pluggable custom dissector generation is performed. In step 845,MIP/Custom Dissector testing is performed. If MIP/Custom Dissectortesting provides a fail result in step 845, in step 850, furtherevaluation is performed using custom dissector code. In step 855, theMIP/Custom Dissector signature is released if pass result is provided instep 845 or based on the custom dissector code in step 850.

In various embodiments, method 800 depicted in FIG. 8 may be performedby an application detection engine. For example, the applicationdetection engine may employ each of a plurality of detectors that, in afirst tier of analysis, inspect one data point for the purposes ofdetecting an application. Based on pass/fail results by individualdetectors, the application detection engine may employ a plurality ofdetectors that, in a second tier of analysis, inspect multiple datapoints for the purposes of detecting applications. Based on pass/failresults by individual detectors, the application detection engine mayemploy one or more custom dissectors that, in a third tier of analysis,cover false positive/false negative scenarios or otherapplication-specific protocols. Whether an inspection engine or detectoroperates as a SIP, MIP, or custom detector may change, as may the orderin which an engine or detector can be invoked.

In further embodiments, method 800 depicted in FIG. 8 may be performedindependently by each of a plurality of inspection engines or detectors.For example, an individual detection engine may, in a first tier ofanalysis, inspect one data point for the purposes of detecting anapplication. Based on pass/fail results, the detection engine may, in asecond tier of analysis, inspect multiple data points for the purposesof detecting applications. Based on pass/fail results, the individualdetectors may invoke or employ one or more custom dissectors that, in athird tier of analysis, cover false positive/false negative scenarios orother application-specific protocols.

FIG. 9 is a simplified block diagram of computer system 900 that mayincorporate embodiments of the present invention. FIG. 9 is merelyillustrative of an embodiment incorporating the present invention anddoes not limit the scope of the invention as recited in the claims. Oneof ordinary skill in the art would recognize other variations,modifications, and alternatives.

In one embodiment, computer system 900 typically includes a monitor 910,a computer 920, user output devices 930, user input devices 940,communications interface 950, and the like.

As shown in FIG. 9, computer 920 may include a processor(s) 960 thatcommunicates with a number of peripheral devices via a bus subsystem990. These peripheral devices may include user output devices 930, userinput devices 940, communications interface 950, and a storagesubsystem, such as random access memory (RAM) 970 and disk drive 980.

User input devices 930 include all possible types of devices andmechanisms for inputting information to computer system 920. These mayinclude a keyboard, a keypad, a touch screen incorporated into thedisplay, audio input devices such as voice recognition systems,microphones, and other types of input devices. In various embodiments,user input devices 930 are typically embodied as a computer mouse, atrackball, a track pad, a joystick, wireless remote, drawing tablet,voice command system, eye tracking system, and the like. User inputdevices 930 typically allow a user to select objects, icons, text andthe like that appear on the monitor 910 via a command such as a click ofa button or the like.

User output devices 940 include all possible types of devices andmechanisms for outputting information from computer 920. These mayinclude a display (e.g., monitor 910), non-visual displays such as audiooutput devices, etc.

Communications interface 950 provides an interface to othercommunication networks and devices. Communications interface 950 mayserve as an interface for receiving data from and transmitting data toother systems. Embodiments of communications interface 950 typicallyinclude an Ethernet card, a modem (telephone, satellite, cable, ISDN),(asynchronous) digital subscriber line (DSL) unit, FireWire interface,USB interface, and the like. For example, communications interface 950may be coupled to a computer network, to a FireWire bus, or the like. Inother embodiments, communications interfaces 950 may be physicallyintegrated on the motherboard of computer 920, and may be a softwareprogram, such as soft DSL, or the like.

In various embodiments, computer system 900 may also include softwarethat enables communications over a network such as the HTTP, TCP/IP,RTP/RTSP protocols, and the like. In alternative embodiments of thepresent invention, other communications software and transfer protocolsmay also be used, for example IPX, UDP or the like.

In some embodiment, computer 920 includes one or more Xeonmicroprocessors from Intel as processor(s) 960. Further, one embodiment,computer 920 includes a UNIX-based operating system.

RAM 970 and disk drive 980 are examples of tangible media configured tostore data such as embodiments of the present invention, includingexecutable computer code, human readable code, or the like. Other typesof tangible media include floppy disks, removable hard disks, opticalstorage media such as CD-ROMS, DVDs and bar codes, semiconductormemories such as flash memories, read-only-memories (ROMS),battery-backed volatile memories, networked storage devices, and thelike. RAM 970 and disk drive 980 may be configured to store the basicprogramming and data constructs that provide the functionality of thepresent invention.

Software code modules and instructions that provide the functionality ofthe present invention may be stored in RAM 970 and disk drive 980. Thesesoftware modules may be executed by processor(s) 960. RAM 970 and diskdrive 980 may also provide a repository for storing data used inaccordance with the present invention.

RAM 970 and disk drive 980 may include a number of memories including amain random access memory (RAM) for storage of instructions and dataduring program execution and a read only memory (ROM) in which fixedinstructions are stored. RAM 970 and disk drive 980 may include a filestorage subsystem providing persistent (non-volatile) storage forprogram and data files. RAM 970 and disk drive 980 may also includeremovable storage systems, such as removable flash memory.

Bus subsystem 990 provides a mechanism for letting the variouscomponents and subsystems of computer 920 communicate with each other asintended. Although bus subsystem 990 is shown schematically as a singlebus, alternative embodiments of the bus subsystem may utilize multiplebusses.

FIG. 9 is representative of a computer system capable of embodying thepresent invention. It will be readily apparent to one of ordinary skillin the art that many other hardware and software configurations aresuitable for use with the present invention. For example, the computermay be a desktop, portable, rack-mounted or tablet configuration.Additionally, the computer may be a series of networked computers.Further, the use of other micro processors are contemplated, such asPentium™ or Itanium™ microprocessors; Opteron™ or AthlonXP™microprocessors from Advanced Micro Devices, Inc; and the like. Further,other types of operating systems are contemplated, such as Windows®,WindowsXP®, WindowsNT®, or the like from Microsoft Corporation, Solarisfrom Sun Microsystems, LINUX, UNIX, and the like. In still otherembodiments, the techniques described above may be implemented upon achip or an auxiliary processing board.

Various embodiments of any of one or more inventions whose teachings maybe presented within this disclosure can be implemented in the form oflogic in software, firmware, hardware, or a combination thereof. Thelogic may be stored in or on a machine-accessible memory, amachine-readable article, a tangible computer-readable medium, acomputer-readable storage medium, or other computer/machine-readablemedia as a set of instructions adapted to direct a central processingunit (CPU or processor) of a logic machine to perform a set of stepsthat may be disclosed in various embodiments of an invention presentedwithin this disclosure. The logic may form part of a software program orcomputer program product as code modules become operational with aprocessor of a computer system or an information-processing device whenexecuted to perform a method or process in various embodiments of aninvention presented within this disclosure. Based on this disclosure andthe teachings provided herein, a person of ordinary skill in the artwill appreciate other ways, variations, modifications, alternatives,and/or methods for implementing in software, firmware, hardware, orcombinations thereof any of the disclosed operations or functionalitiesof various embodiments of one or more of the presented inventions.

The disclosed examples, implementations, and various embodiments of anyone of those inventions whose teachings may be presented within thisdisclosure are merely illustrative to convey with reasonable clarity tothose skilled in the art the teachings of this disclosure. As theseimplementations and embodiments may be described with reference toexemplary illustrations or specific figures, various modifications oradaptations of the methods and/or specific structures described canbecome apparent to those skilled in the art. All such modifications,adaptations, or variations that rely upon this disclosure and theseteachings found herein, and through which the teachings have advancedthe art, are to be considered within the scope of the one or moreinventions whose teachings may be presented within this disclosure.Hence, the present descriptions and drawings should not be considered ina limiting sense, as it is understood that an invention presented withina disclosure is in no way limited to those embodiments specificallyillustrated.

Accordingly, the above description and any accompanying drawings,illustrations, and figures are intended to be illustrative but notrestrictive. The scope of any invention presented within this disclosureshould, therefore, be determined not with simple reference to the abovedescription and those embodiments shown in the figures, but insteadshould be determined with reference to the pending claims along withtheir full scope or equivalents.

What is claimed is:
 1. A non-transitory computer-readable storage mediumstoring code executable by one or more processors of one or more of aplurality of computer systems for detecting network-based applications,the non-transitory computer-readable storage medium comprising: code forreceiving at a first set of one or more computer systems in theplurality of computer systems information describing one or more datapoints, the one or more data points identified in response to ananalysis of network traffic sent to or received from a networkapplication to identify a set of data points associated with the networktraffic that are characteristic of the network-based application; codefor associating with the first set of one or more computer systems inthe plurality of computer systems the information describing theidentified one or more data points with the network-based application;code for storing with the first set of one or more computer systems inthe plurality of computer systems information about the network-basedapplication, the information describing the identified one or more datapoints, and information associating the information describing theidentified one or more data points and the network-based application ina database; code for generating with a second set of one or morecomputer systems in the plurality of computer systems a set of rules inresponse to accessing the database that configure an applicationdetection engine to identify the network-based application from networktraffic, each rule in the set of rules specifying at least one of theone or more identified data points and one or more conditions when datain the network traffic associated with the at least one of the one ormore identified data points satisfies the rule; and code forcommunicating from one or more computer systems in the plurality ofcomputer systems the set of rules to an application detection device,wherein at least application detection functionality of the applicationdetection device is dynamically updated to support detection of thenetwork-based application based on the communicated set of rules.
 2. Thenon-transitory computer-readable storage medium of claim 1 wherein thecode for receiving the one or more data points comprises code forreceiving one or more of a source address, a destination address, asource port, a destination port, one or more header fields, payloaddata, or combinations thereof.
 3. The non-transitory computer-readablestorage medium of claim 1 further comprising: code for receiving one ormore of a filename, a download location, a URL, a hostname, or a domainname associated with the network-based application; and code for storinginformation associating the one or more of a filename, a downloadlocation, a URL, a hostname, or a domain name associated with thenetwork-based application with the network-based application in thedatabase.
 4. The non-transitory computer-readable storage medium ofclaim 1 further comprising: code for packaging the set of rules into aformat appropriate for the application detection device.
 5. Thenon-transitory computer-readable storage medium of claim 1 furthercomprising: code for receiving information describing logic fordetermining information using one or more of the identified one or moredata points; code for associating the logic with the network-basedapplication; and code for storing the logic and information associatingthe logic and the network-based application in the database.
 6. Thenon-transitory computer-readable storage medium of claim 5 furthercomprising: code for generating program code based on the logic; andcode for compiling the program code for execution at the applicationdetection device.
 7. The non-transitory computer-readable storage mediumof claim 6 wherein the code for compiling the program code for executionat the application detection device comprises code for compiling theprogram code for dynamic loading at the application detection device. 8.The non-transitory computer-readable storage medium of claim 6 whereinthe code for communicating the set of rules to the application detectiondevice further comprise code for communicating the compiled programcode, wherein at least the application detection functionality of theapplication detection device is dynamically updated to support detectionof the network-based application based on the communicated set of rulesand the compiled program code.
 9. The non-transitory computer-readablestorage medium of claim 5 wherein the code for receiving the informationdescribing the logic comprises code for receiving logic for maintainingstating information across the network traffic.
 10. The non-transitorycomputer-readable storage medium of claim 5 wherein the code forreceiving the information describing the logic comprises code forreceiving logic for determining one or more hash values or checksum fromthe network traffic.
 11. The method of claim 1 wherein the dynamicupdated of at least the application detection functionality of theapplication detection device to support detection of the network-basedapplication based on the communicated set of rules comprises updatedduring run-time.
 12. The method of claim 1 wherein at least one or moreuser interfaces of the application detection device are dynamicallyupdated to support displaying of information associated with thenetwork-based application based on the communicated set of rules. 13.The method of claim 1 wherein at least reporting functionality of theapplication detection device is dynamically updated to support reportingof information associated with the network-based application based onthe communicated set of rules.
 14. A non-transitory computer-readablestorage medium storing code executable by one or more processors of oneor more of a plurality of computer systems for detecting network-basedapplications, the non-transitory computer-readable storage mediumcomprising: code for receiving at a first set it one or more computersystems in the plurality of computer systems information describing oneor more data points, the one or more data points identified in responseto an analysis of network traffic sent to or received from a networkapplication to identify a set of data points associated with the networktraffic that are characteristic of the network-based application; codefor associating with the first set of one or more computer systems inthe plurality of computer systems the information describing theidentified one or more data points with the network-based application;code for storing with the first set of one or more computer systems inthe plurality of computer systems information about the network-basedapplication, the information describing the identified one or more datapoints, and information associating the information describing theidentified one or more data points and the network-based application ina database; code for generating with a second set of one or morecomputer systems in the plurality of computer systems a set of rules inresponse to accessing the database that configure an applicationdetection engine to identify the network-based application from networktraffic, each rule in the set of rules specifying at least one of theone or more identified data points and one or more conditions when datain the network traffic associated with the at least one of the one ormore identified data points satisfies the rule; and code forcommunicating from one or more computer systems in the plurality ofcomputer systems the set of rules to an application detection device,wherein at least application detection functionality of the applicationdetection device is dynamically updated to support detection of thenetwork-based application based on the communicated set of rules. 15.The non-transitory computer-readable storage medium of claim 14 whereinthe code for receiving the one or more data points comprises code forreceiving one or more of a source address, a destination address, asource port, a destination port, one or more header fields, payloaddata, or combinations thereof.
 16. The non-transitory computer-readablestorage medium of claim 14 further comprising: code for receiving one ormore of a filename, a download location, a URL, a hostname, or a domainname associated with the network-based application; and code for storinginformation associating the one or more of a filename, a downloadlocation, a URL, a hostname, or a domain name associated with thenetwork-based application with the network-based application in thedatabase.
 17. The non-transitory computer-readable storage medium ofclaim 14 further comprising: code for packaging the set of rules into aformat appropriate for the application detection device.
 18. Thenon-transitory computer-readable storage medium of claim 14 furthercomprising: code for receiving information describing logic fordetermining information using one or more of the identified one or moredata points; code for associating the logic with the network-basedapplication; and code for storing the logic and information associatingthe logic and the network-based application in the database.
 19. Thenon-transitory computer-readable storage medium of claim 18 furthercomprising: code for generating program code based on the logic; andcode for compiling the program code for execution at the applicationdetection device.
 20. The non-transitory computer-readable storagemedium of claim 19 wherein the code for compiling the program code forexecution at the application detection device comprises code forcompiling the program code for dynamic loading at the applicationdetection device.
 21. The non-transitory computer-readable storagemedium of claim 19 wherein the code for communicating the set of rulesto the application detection device further comprise code forcommunicating the compiled program code, wherein at least theapplication detection functionality of the application detection deviceis dynamically updated to support detection of the network-basedapplication based on the communicated set of rules and the compiledprogram code.
 22. The non-transitory computer-readable storage medium ofclaim 18 wherein the code for receiving the information describing thelogic comprises code for receiving logic for maintaining statinginformation across the network traffic.
 23. The non-transitorycomputer-readable storage medium of claim 18 wherein the code forreceiving the information describing the logic comprises code forreceiving logic for determining one or more hash values or checksum fromthe network traffic.
 24. A system for detecting network-basedapplications, the system comprising: a database configured to storeinformation about a network-based application; a first set of one ormore computer systems configured to: receive information describing theone or more data points, the one or more data points determined inresponse to an analysis of network traffic sent to or received from thenetwork application to identify a set of data points associated with thenetwork traffic that are characteristic of the network-basedapplication, associate the information describing the identified one ormore data points with the network-based application, and store theinformation about the network-based application, the informationdescribing the identified one or more data points, and informationassociating the information describing the identified one or more datapoints and the network-based application in the database; and a secondset of one or more computer systems configured to: generate a set ofrules in response to accessing the database that configure anapplication detection engine to identify the network-based applicationfrom network traffic, each rule in the set of rules specifying at leastone of the one or more identified data points and one or more conditionswhen data in the network traffic associated with the at least one of theone or more identified data points satisfies the rule, and communicatethe set of rules to an application detection device, wherein at leastapplication detection functionality of the application detection deviceis dynamically updated to support detection of the network-basedapplication based on the communicated set of rules.